Coverage decreased (-0.2%) to 96.654% when pulling ada645c on mattiash:buffertime-typings into c05a945 on ReactiveX:master.

My two cents: Is this consistent with other parts of the API? Are there other places where null is used rather than undefined? I can't recall an API method to which null is passed to indicate that a parameter is not specified in a call; I can only recall those to which undefined is passed.

For example, undefined is used to to subscribe. This is okay:

of(1).subscribe(undefined);

Whereas this is not:

of(1).subscribe(null); // [ts] Argument of type 'null' is not assignable to parameter of type '((value: number) => void) | undefined'.

For consistency, I think it should be undefined, rather than null. Or all of the typings should be changed to accept either null or undefined for parameters that are to be ignored.

The tests pass in null for bufferCreationInterval: https://github.com/ReactiveX/rxjs/blob/master/spec/operators/bufferTime-spec.ts#L24

The code sets bufferCreationInterval to null if the parameter is not included:
https://github.com/ReactiveX/rxjs/blob/master/src/internal/operators/bufferTime.ts#L67

and it later checks if it is null:
https://github.com/ReactiveX/rxjs/blob/master/src/internal/operators/bufferTime.ts#L129

Changing it to undefined is a much bigger change, but I have nothing against it.

Changing it to undefined is a much bigger change ...

Yeah, you are right. It would be a bigger change and smaller changes are always more appealing.

Regarding the check against null, the check uses == which will return true for either undefined or null. That's the mechanism used throughout the Angular codebase, IIRC.

Anyway, others can decide, I just thought I'd point out the consistency issue.

Thanks for the PR, BTW. 👍

Yeah, this should probably be number|null|undefined. (honestly we have other places that only accept undefined that should probably accept null as well. I don't think there are any major penalties for that.

Thanks, @mattiash!